Closed
Bug 1017769
Opened 10 years ago
Closed 10 years ago
HTTPS proxy CONNECT leaks Host header of tunneled request
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla32
People
(Reporter: david, Assigned: david)
Details
Attachments
(2 files)
2.42 KB,
application/zip
|
Details | |
1.95 KB,
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
1. Start an HTTPS proxy with logging of requests (for example, "ncat -l --proxy-type http -vvv"). 2. Configure Firefox to use an HTTPS proxy (localhost:3128 if using the ncat command). 3. Extract the attached proxy-host-test@example.com extension to the extensions directory. The extension opens an nsIHttpChannel to "https://www.google.com/test" but sets the Host header to "cors-test.appspot.com". 4. Run Firefox and watch the requests to the proxy. (The extension is a browser overlay, so you can get it to run again by opening a new window.) The proxy CONNECT request has www.google.com in the Request-Line but cors-test.appspot.com in the Host header: CONNECT www.google.com:443 HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Proxy-Connection: keep-alive Connection: keep-alive Host: cors-test.appspot.com What would be better for me is if the Host header also said www.google.com. The attached patch does it: CONNECT www.google.com:443 HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Proxy-Connection: keep-alive Connection: keep-alive Host: www.google.com:443 Since bug 82388, nsHttpConnection::MakeConnectString peeks into the plaintext of the tunneled request, in order to copy the Host header into the proxy CONNECT request (https://hg.mozilla.org/mozilla-central/file/1e712b724d17/netwerk/protocol/http/nsHttpConnection.cpp#l1762). The Request-URI host:port string, on the other hand, is constructed out of the destination info. The Host header in the proxy request is only there because HTTP/1.1 requires it (see discussion on bug 82388). In most cases these two strings will be the same; but when they are not, it's better to avoid revealing parts of the tunneled request. Note that changing the Host header on the proxy request doesn't affect the Host header in the tunneled request. The tunneled host header is unchanged and is interpreted by the remote server. In this example, you can set browser.dom.window.dump_enabled and see that the result of the request is the expected '{"status":"ok"}' from https://cors-test.appspot.com/test, and not the 404 from https://www.google.com/test. Why would anyone want to do this weird thing? Send a request with a Host header different from the authority in the URL? We are investigating it as a technique for circumventing Internet censorship--it appears to a censor that you are contacting one domain, when you are actually contacting another. (In this case, www.google.com internally dispatches the request to an appspot.com server.) We're using a Firefox extension as an HTTPS camouflage layer, and it works well. It would be even better to use the same system through an upstream HTTP proxy, without revealing the covert destination. https://trac.torproject.org/projects/tor/ticket/12146 is this issue on Tor's bug tracker.
Assignee | ||
Comment 1•10 years ago
|
||
Patch to make nsHttpConnection::MakeConnectString use the same string for Host as it uses for Request-URI.
Comment 2•10 years ago
|
||
I'll take the patch with a green try run.
Assignee | ||
Comment 3•10 years ago
|
||
How do I do that? I don't have a commit account.(In reply to Patrick McManus [:mcmanus] from comment #2) > I'll take the patch with a green try run. How do I do that? I don't have a commit account.
Comment 4•10 years ago
|
||
(In reply to david from comment #3) > How do I do that? I don't have a commit account.(In reply to Patrick McManus > [:mcmanus] from comment #2) > > I'll take the patch with a green try run. > > How do I do that? I don't have a commit account. I take care of it.
Comment 5•10 years ago
|
||
(In reply to Patrick McManus [:mcmanus] from comment #2) > I'll take the patch with a green try run. Try is green: https://tbpl.mozilla.org/?tree=Try&rev=6350cf56b7b4
Updated•10 years ago
|
Attachment #8431005 -
Flags: review?(mcmanus)
Comment 6•10 years ago
|
||
actually - can you run all the tests (on just one platform) - the CI uses a lot of proxy connects
Updated•10 years ago
|
Attachment #8431005 -
Flags: review?(mcmanus) → review+
Comment 7•10 years ago
|
||
green as well: https://tbpl.mozilla.org/?tree=Try&rev=6c98dca0c285
Comment 8•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/a1f6458800d4 Should this have a test or is it covered by existing ones?
Flags: in-testsuite?
Keywords: checkin-needed
Comment 9•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a1f6458800d4
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in
before you can comment on or make changes to this bug.
Description
•